Automatic buffer sizing for optimal network-on-chip design

ABSTRACT

The present disclosure relates to automatic sizing of NoC channel buffers of one or more virtual channels to optimize NoC design, SoC design, and to meet defined performance objectives. The present disclosure further relates to a NoC element such as a router or a bridge having input ports associated with input virtual channels, and output ports associated with output virtual channels, wherein, aspects of the present disclosure enable sizing of any or a combination of the width of the input virtual channel(s), width of the output virtual channel(s), buffer(s) associated with input virtual channels, and buffer(s) associated with output virtual channels. In another aspect, the sizing can be performed based on one or a combination of defined performance objectives, throughputs of the input virtual channels, and throughputs of the output virtual channels, load characteristics, bandwidth characteristics of each input/output channel, among other like parameters.

BACKGROUND

Technical Field

Methods and example implementations described herein are directed tointerconnect architecture, and more specifically, to buffers within aNetwork on Chip (NoC) system interconnect architecture for optimal NoCand system design.

Related Art

The number of components on a chip is rapidly growing due to increasinglevels of integration, system complexity and shrinking transistorgeometry. Complex System-on-Chips (SoCs) may involve a variety ofcomponents e.g., processor cores, DSPs, hardware accelerators, memoryand I/O, while Chip Multi-Processors (CMPs) may involve a large numberof homogenous processor cores, memory and I/O subsystems. In both SoCand CMP systems, the on-chip interconnect plays a role in providinghigh-performance communication between the various components. Due toscalability limitations of traditional buses and crossbar basedinterconnects, Network-on-Chip (NoC) has emerged as a paradigm tointerconnect a large number of components on the chip. NoC is a globalshared communication infrastructure made up of several routing nodesinterconnected with each other using point-to-point physical links thatdenote connectivity and direction of data flow within the SoC and theNoC.

Messages are injected by the source and are routed from the source nodeto the destination over multiple intermediate nodes and physical links.The destination node then ejects the message and provides the message tothe destination. For the remainder of this application, the terms‘components’, ‘blocks’, ‘hosts’ or ‘cores’ will be used interchangeablyto refer to the various system components which are interconnected usinga NoC. Terms ‘routers’ and ‘nodes’ will also be used interchangeably.Without loss of generalization, the system with multiple interconnectedcomponents will itself be referred to as a ‘multi-core system’.

There are several topologies in which the routers can connect to oneanother to create the system network. Bi-directional rings (as shown inFIG. 1(a)), 2-D (two dimensional) mesh (as shown in FIG. 1(b)) and 2-DTaurus (as shown in FIG. 1(c)) are examples of topologies in the relatedart. Mesh and Taurus can also be extended to 2.5-D (two and halfdimensional) or 3-D (three dimensional) organizations. FIG. 1(d) shows a3D mesh NoC, where there are three layers of 3×3 2D mesh NoC shown overeach other. The NoC routers have up to two additional ports, oneconnecting to a router in the higher layer, and another connecting to arouter in the lower layer. Router 111 in the middle layer of the examplehas both ports used, one connecting to the router at the top layer andanother connecting to the router at the bottom layer. Routers 110 and112 are at the bottom and top mesh layers respectively, therefore theyhave only the upper facing port 113 and the lower facing port 114respectively connected.

Packets are message transport units for intercommunication betweenvarious components. Routing involves identifying a path composed of aset of routers and physical links of the network over which packets aresent from a source to a destination. Components are connected to one ormultiple ports of one or multiple routers; with each such port having aunique ID. Packets carry the destination's router and port ID for use bythe intermediate routers to route the packet to the destinationcomponent.

Examples of routing techniques include deterministic routing, whichinvolves choosing the same path from A to B for every packet. This formof routing is independent from the state of the network and does notload balance across path diversities, which might exist in theunderlying network. However, such deterministic routing may implementedin hardware, maintains packet ordering and may be rendered free ofnetwork level deadlocks. For example, shortest path routing may minimizethe latency as such routing reduces the number of hops from the sourceto the destination(s) or the cost of routing the packet from the sourceto the destination(s), wherein the cost of routing depends on thebandwidth available. For this reason, the shortest path may also be thelowest power path for communication between the two components.Dimension-order routing is a form of deterministic shortest path routingin 2-D, 2.5-D, and 3-D mesh networks. In this routing scheme, messagesare routed along each coordinates in a particular sequence until themessage reaches the final destination. For example in a 3-D meshnetwork, one may first route along the X dimension until it reaches arouter whose X-coordinate is equal to the X-coordinate of thedestination router. Next, the message takes a turn and is routed inalong Y dimension and finally takes another turn and moves along the Zdimension until the message reaches the final destination router.Dimension ordered routing may be minimal turn and shortest path routing.

FIG. 2(a) pictorially illustrates an example of XY routing in a twodimensional mesh. More specifically, FIG. 2(a) illustrates XY routingfrom node ‘34’ to node ‘00’. In the example of FIG. 2(a), each componentis connected to only one port of one router. A packet is first routedover the x-axis till the packet reaches node ‘04’ where the x-coordinateof the node is the same as the x-coordinate of the destination node. Thepacket is next routed over the y-axis until the packet reaches thedestination node.

In heterogeneous mesh topology in which one or more routers or one ormore links are absent, dimension order routing may not be feasiblebetween certain source and destination nodes, and alternative paths mayhave to be taken. The alternative paths may not be shortest or minimumturn.

Source routing and routing using tables are other routing options usedin NoC. Adaptive routing can dynamically change the path taken betweentwo points on the network based on the state of the network. This formof routing may be complex to analyze and implement.

A NoC interconnect may contain multiple physical networks. Over eachphysical network, there may exist multiple virtual networks, whereindifferent message types are transmitted over different virtual networks.In this case, at each physical link or channel, there are multiplevirtual channels; each virtual channel may have dedicated buffers atboth end points. In any given clock cycle, only one virtual channel cantransmit data on the physical channel.

The physical channels are time sliced into a number of independentlogical channels called virtual channels (VCs). VCs provide multipleindependent paths to route packets, however they are time-multiplexed onthe physical channels. A virtual channel holds the state needed tocoordinate the handling of the flits of a packet over a channel. At aminimum, this state identifies the output channel of the current nodefor the next hop of the route and the state of the virtual channel(idle, waiting for resources, or active). The virtual channel may alsoinclude pointers to the flits of the packet that are buffered on thecurrent node and the number of flit buffers available on the next node.

NoC interconnects may employ wormhole routing, wherein, a large messageor packet is broken into small pieces known as flits (also referred toas flow control digits). The first flit is the header flit, which holdsinformation about this packet's route and key message level info alongwith payload data and sets up the routing behavior for all subsequentflits associated with the message. Optionally, one or more body flitsfollows the head flit, containing the remaining payload of data. Thefinal flit is the tail flit, which in addition to containing the lastpayload also performs some bookkeeping to close the connection for themessage. In wormhole flow control, virtual channels are oftenimplemented.

The term “wormhole” plays on the way messages are transmitted over thechannels: the output port at the next router can be so short thatreceived data can be translated in the head flit before the full messagearrives. This allows the router to quickly set up the route upon arrivalof the head flit and then opt out from the rest of the conversation.Since a message is transmitted flit by flit, the message may occupyseveral flit buffers along its path at different routers, creating aworm-like image.

Based upon the traffic between various end points, and the routes andphysical networks that are used for various messages, different physicalchannels of the NoC interconnect may experience different levels of loadand congestion. The capacity of various physical channels of a NoCinterconnect is determined by the width of the channel (number ofphysical wires) and the clock frequency at which it is operating.Various channels of the NoC may operate at different clock frequencies,and various channels may have different widths based on the bandwidthrequirement at the channel. The bandwidth requirement at a channel isdetermined by the flows that traverse over the channel and theirbandwidth values. Flows traversing over various NoC channels areaffected by the routes taken by various flows. In a mesh or Taurus NoC,there may exist multiple route paths of equal length or number of hopsbetween any pair of source and destination nodes. For example, in FIG.2(b), in addition to the standard XY route between nodes 34 and 00,there are additional routes available, such as YX route 203 or amulti-turn route 202 that makes more than one turn from source todestination.

In a NoC with statically allocated routes for various traffic slows, theload at various channels may be controlled by intelligently selectingthe routes for various flows. When a large number of traffic flows andsubstantial path diversity is present, routes can be chosen such thatthe load on all NoC channels is balanced nearly uniformly, thus avoidinga single point of bottleneck. Once routed, the NoC channel widths can bedetermined based on the bandwidth demands of flows on the channels.Unfortunately, channel widths cannot be arbitrarily large due tophysical hardware design restrictions, such as timing or wiringcongestion. There may be a limit on the maximum channel width, therebyputting a limit on the maximum bandwidth of any single NoC channel.

Additionally, wider physical channels may not help in achieving higherbandwidth if messages are short. For example, if a packet is a singleflit packet with a 64-bit width, then no matter how wide a channel is,the channel will only be able to carry 64 bits per cycle of data if allpackets over the channel are similar. Thus, a channel width is alsolimited by the message size in the NoC. Due to these limitations on themaximum NoC channel width, a channel may not have enough bandwidth inspite of balancing the routes.

To address the above bandwidth concern, multiple parallel physical NoCsmay be used. Each NoC may be called a layer, thus creating a multi-layerNoC architecture. Hosts inject a message on a NoC layer; the message isthen routed to the destination on the NoC layer, where it is deliveredfrom the NoC layer to the host. Thus, each layer operates more or lessindependently from each other, and interactions between layers may onlyoccur during the injection and ejection times. FIG. 3(a) illustrates atwo layer NoC. Here the two NoC layers are shown adjacent to each otheron the left and right, with the hosts connected to the NoC replicated inboth left and right diagrams. A host is connected to two routers in thisexample—a router in the first layer shown as R1, and a router is thesecond layer shown as R2. In this example, the multi-layer NoC isdifferent from the 3D NoC, i.e. multiple layers are on a single silicondie and are used to meet the high bandwidth demands of the communicationbetween hosts on the same silicon die. Messages do not go from one layerto another. For purposes of clarity, the present application willutilize such a horizontal left and right illustration for multi-layerNoC to differentiate from the 3D NoCs, which are illustrated by drawingthe NoCs vertically over each other.

In FIG. 3(b), a host connected to a router from each layer, R1 and R2respectively, is illustrated. Each router is connected to other routersin its layer using directional ports 301, and is connected to the hostusing injection and ejection ports 302. A bridge-logic 303 may sitbetween the host and the two NoC layers to determine the NoC layer foran outgoing message and sends the message from host to the NoC layer,and also perform the arbitration and multiplexing between incomingmessages from the two NoC layers and delivers them to the host.

In a multi-layer NoC, the number of layers needed may depend upon anumber of factors such as the aggregate bandwidth requirement of alltraffic flows in the system, the routes that are used by various flows,message size distribution, maximum channel width, etc. Once the numberof NoC layers in NoC interconnect is determined in a design, differentmessages and traffic flows may be routed over different NoC layers.Additionally, one may design NoC interconnects such that differentlayers have different topologies in number of routers, channels andconnectivity. The channels in different layers may have different widthsbased on the flows that traverse over the channel and their bandwidthrequirements.

In a NoC interconnect, if the traffic profile is not uniform and thereis a certain amount of heterogeneity (e.g., certain hosts talking toeach other more frequently than the others), the interconnectperformance may depend on the NoC topology and where various hosts areplaced in the topology with respect to each other and to what routersthey are connected to. For example, if two hosts talk to each otherfrequently and require higher bandwidth than other interconnects, thenthey should be placed next to each other. This will reduce the latencyfor this communication which thereby reduces the global average latency,as well as reduce the number of router nodes and links over which thehigher bandwidth of this communication must be provisioned.

As the number of chip components are growing, and NoC and SoC are beingconfigured to support varying traffic profiles that have randomness andburstiness, it is desired to configure NoC channels and/or buffers thatefficiently support such varying trafficcharacteristics/specification/conditions to minimize the impact of suchvarying conditions on experience, congestion, among other performanceparameters.

Therefore, there is need for a method, system, and non-transitorycomputer implementation for sizing channel and/or buffer attributes suchas channel width, channel depth, and sizing of buffers of channels so asto get an optimal NoC and system design that meet performance objectivesof SoC and/or NoC.

SUMMARY

Methods, non-transitory computer readable mediums, and systems aredescribed for automatically sizing NoC channel buffers of one or morevirtual channels in order to optimize the NoC design, SoC design, and tomeet defined performance objectives. Methods, non-transitory computerreadable mediums, and systems are described for a NoC element such as arouter or a bridge having input ports associated with input virtualchannels, and output ports associated with output virtual channels,wherein, in an aspect, the proposed method enables sizing of any or acombination of the width of the input virtual channel(s), width of theoutput virtual channel(s), buffer(s) associated with input virtualchannels, and buffer(s) associated with output virtual channels. Inanother aspect, the sizing can be performed based on one or acombination of defined performance objectives, throughputs of the inputvirtual channels, and throughputs of the output virtual channels, loadcharacteristics, bandwidth characteristics of each input/output channel,among other like parameters.

Aspects of the present disclosure provide a method for computing thebandwidth for a given NoC channel, say in terms of flits per cycle, andthen sizing the width of the NoC channel based on the computed width,wherein, for instance, in case the load on the channel is computed to begreater than 1.0, width of the channel can be increased to bring it toless than or equal to 1.0. In an example embodiment, method of thepresent disclosure can also enable provisioning of additional bandwidthin order to cater for randomness in traffic and prevent loss ofefficiency.

Aspects of the proposed method can further include oversizing of one ormore channels associated with a NoC element, such as a router, in orderto prevent arbitration conflict, wherein the extent of oversizing can bedetermined based on one or a combination of traffic specification,traffic distribution, input/output port configuration, virtual channelconfiguration, router/NoC element design, efficiency of router/NoCelement, efficient of channel, among other parameters/attributes.Oversizing can further be configured to cater randomness and burstinessin the traffic flow. In another aspect, oversizing of one or morechannels can also be defined based on user specific/configured/definedefficiency levels.

Aspects of the proposed method can further include changing the width ofone or more input and/or output virtual channels depending on the widthof their corresponding channels. For instance, in case the incomingchannels of a given router have a capacity of 64 bits/cycle and theoutput channel has a capacity of 128 bits/cycle, size of the incomingchannels can be automatically changed to have a capacity of 128bits/cycle. Similarly, in case the input channels of a given router havea capacity of 128 bits/cycle, and the output channel has a capacity of64 bits/cycle, size of the output channel can be automatically changedto have a capacity of 128 bits/cycle and accommodate traffic from boththe input ports with minimal efficiency loss. In an alternateembodiment, in case the input channels of a given router have a capacityof 64 bits/cycle, and the output channel has a capacity of 128bits/cycle, buffer size of the input channels can be increased toaccommodate/buffer the complete packet (from start of packet (SOP) toend of packet (EOP)) before the same is transmitted in a single go tothe 128 bits/cycle output channel. Such a router configuration can bemarked and/or rendered as a store and forward router.

Aspects of the present system further include means for sizing a channelbased on flow control, wherein, for instance, in case it is determinedby the proposed system that the router sending a request works at adifferent clock frequency (C1) when compared with the clock frequency(C2) of the receiving router, as the router times aredifferent/increase, buffer size of the receiving buffers can becontrolled/managed to enable efficient throughput. In another exampleaspect, in case the proposed system determines that the read frequencyis less than write frequency, then there exists no need to maintain fullthroughput by means of additional buffer size as the read throughput ismore than the write throughput and the drain rate at thefirst-input-first-output (FIFO) buffer would be lower. On the otherhand, in case the read frequency is more than or equal to the writefrequency, the buffer (FIFO-based) size can be deepened.

Aspects of the present system further include sizing of the buffersbased on bandwidth requirement, project load conditions, expectedrandomness/burstiness, among other like parameters. For instance, systemof the present disclosure can be configured to compute the bandwidthrequirement of each virtual channel in terms of expected number of flitsof data, based on which the system can reduce the size of the FIFObuffer, such that if the bandwidth requirement is less than 1 per cycle,the system can reduce the FIFO buffer accordingly and maintain thedesired throughput.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1(a), 1(b) 1(c) and 1(d) illustrate examples of Bidirectionalring, 2D Mesh, 2D Taurus, and 3D Mesh NoC Topologies.

FIG. 2(a) illustrates an example of XY routing in a related art twodimensional mesh.

FIG. 2(b) illustrates three different routes between a source anddestination nodes.

FIG. 3(a) illustrates an example of a related art two layer NoCinterconnect.

FIG. 3(b) illustrates the related art bridge logic between host andmultiple NoC layers.

FIG. 4A and FIG. 4B illustrates example NoC components having multipleinput and output ports connecting the NoC component with other NoCcomponents using virtual channels that may cause loss of efficiency dueto NoC component (router) arbitration.

FIG. 5A and FIG. 5B illustrates example NoC components that can useautomatic sizing of channels and buffer in accordance with an embodimentof the present disclosure.

FIG. 5C illustrates example NoC components wherein the size of thebuffer and data forwarding can be based on flow control in accordancewith an embodiment of the present disclosure.

FIG. 6 illustrated a shared buffer for input VC of NoC component inaccordance with an embodiment of the present disclosure.

FIG. 7 illustrates a flow chart for automatic sizing of input channel,sizing of output channel and sizing of buffers in accordance with anembodiment of the present disclosure.

FIG. 8 illustrates an example computer system on which exampleimplementations may be implemented.

DETAILED DESCRIPTION

The following detailed description provides further details of thefigures and example implementations of the present application.Reference numerals and descriptions of redundant elements betweenfigures are omitted for clarity. Terms used throughout the descriptionare provided as examples and are not intended to be limiting. Forexample, the use of the term “automatic” may involve fully automatic orsemi-automatic implementations involving user or administrator controlover certain aspects of the implementation, depending on the desiredimplementation of one of ordinary skill in the art practicingimplementations of the present application.

Example implementations may involve power management sequences andautomatic power management systems. Examples and description of suchsequences and systems are described in U.S. application Ser. No.14/495,689 (filed Sep. 24, 2014) and Ser. No. 14/498,907 (filed Sep. 26,2014), the disclosures of which are hereby incorporated by reference intheir entirety for all purposes.

Methods, non-transitory computer readable mediums, and systems aredescribed for automatically sizing NoC channel buffers of one or morevirtual channels in order to optimize the NoC design, SoC design, and tomeet defined performance objectives. Methods, non-transitory computerreadable mediums, and systems are described for a NoC element such as arouter or a bridge having input ports associated with one or more inputvirtual channels, and output ports associated with one or more outputvirtual channels, wherein, in an aspect, the proposed method enablessizing of any or a combination of the width of the input virtualchannel(s), width of the output virtual channel(s), buffer(s) associatedwith input virtual channels, and buffer(s) associated with outputvirtual channels. In another aspect, the sizing can be performed basedon one or a combination of defined performance objectives, throughputsof the one or more input virtual channels, throughputs of the outputvirtual channels, load characteristics, bandwidth characteristics ofeach input/output channel, among other like parameters.

Aspects of the present disclosure provide a method for computing thebandwidth for a given NoC channel, say in terms of flits per cycle, andthen sizing the width of the NoC channel based on the computed width,wherein, for instance, in case the load on the channel is computed to begreater than 1.0, width of the channel can be increased to bring it toless than or equal to 1.0. In an example embodiment, method of thepresent disclosure can also enable provisioning of additional bandwidthin order to cater for randomness in traffic and prevent loss ofefficiency.

Aspects of the proposed method can further include oversizing of one ormore channels associated with a NoC element, such as a router, in orderto prevent arbitration conflict, wherein the extent of oversizing can bedetermined based on one or a combination of traffic specification,traffic distribution, input/output port configuration, virtual channelconfiguration, router/NoC element design, efficiency of router/NoCelement, efficient of channel, among other parameters/attributes.Oversizing can further be configured to cater randomness and burstinessin the traffic flow. In another aspect, oversizing of one or morechannels can also be defined based on user specific/configured/definedefficiency levels.

Aspects of the proposed method can further include changing the width ofone or more input and/or output virtual channels depending on the widthof their corresponding channels. For instance, in case the incomingchannels of a given router have a capacity of 64 bits/cycle and theoutput channel has a capacity of 128 bits/cycle, size of the incomingchannels can be automatically changed to have a capacity of 128bits/cycle. Similarly, in case the input channels of a given router havea capacity of 128 bits/cycle, and the output channel has a capacity of64 bits/cycle, size of the output channel can be automatically changedto have a capacity of 128 bits/cycle and accommodate traffic from boththe input ports with minimal efficiency loss. In an alternateembodiment, in case the input channels of a given router have a capacityof 64 bits/cycle, and the output channel has a capacity of 128bits/cycle, buffer size of the input channels can be increased toaccommodate/buffer the complete packet (from start of packet (SOP) toend of packet (EOP)) before the same is transmitted in a single go tothe 128 bits/cycle output channel. Such a router configuration can bemarked and/or rendered as a store and forward router.

Aspects of the present system further include means for sizing a channelbased on flow control, wherein, for instance, in case it is determinedby the proposed system that the router sending a request works at adifferent clock frequency (C1) when compared with the clock frequency(C2) of the receiving router, as the router times aredifferent/increase, buffer size of the receiving buffers can becontrolled/managed to enable efficient throughput. In another exampleaspect, in case the proposed system determines that the read frequencyis less than write frequency, then there exists no need to maintain fullthroughput by means of additional buffer size as the read throughput ismore than the write throughput and the drain rate at thefirst-input-first-output (FIFO) buffer would be lower. On the otherhand, in case the read frequency is more than or equal to the writefrequency, the buffer (FIFO-based) size can be deepened.

Aspects of the present system further include sizing of the buffersbased on bandwidth requirement, project load conditions, expectedrandomness/burstiness, among other like parameters. For instance, systemof the present disclosure can be configured to compute the bandwidthrequirement of each virtual channel in terms of expected number of flitsof data, based on which the system can reduce the size of the FIFObuffer, such that if the bandwidth requirement is less than 1 per cycle,the system can reduce the FIFO buffer accordingly and maintain thedesired throughput.

Aspects of the present disclosure are directed to methods,non-transitory computer readable mediums, and systems for sizing thedepth of input virtual channel and/or depth of output virtual channelbased on one or more performance objectives, throughputs of the inputvirtual channels, and throughout of the output virtual channels.According an example embodiment, throughput of the input virtualchannels and throughput of the output virtual channels can be based onor can be derived from one or more of clock frequencies of channels,channel width, rate of traffic, and given traffic specification of theNoC and SoC. According to another example embodiment, the performanceobjective can be based on one or a combination of rate of traffic,message size, distribution of message size or channel width, channelclock frequency, arbitration efficiency of the NoC components, trafficburstiness, user-specified over provisioning, among other likeparameters. According to yet another example embodiment, buffer size canbe adjusted based on one or a combination of a defined performanceobjective, packet size, input/output message sizes, and input/outputmessage rates, flow control round trip time between a transmittinghardware element and a receiving hardware element, frequency of atransmitting hardware element and a receiving hardware element, amongother like parameters.

In an example implementation, sizing of a NoC channel can includeincreasing/decreasing the width of the channel based on thebandwidth/load requirement, wherein the bandwidth/load requirement canbe calculated based on one or a combination of flows on the channel,message sizes of the flows, distribution of various messages, existingwidth of the channel, clock frequency of the channel, among otherappropriate parameters. In an aspect, bandwidth requirement can becomputed in terms of flits per cycle of the channel, based on whichwidth of the channel can be changed (increased or decreased). In aninstance, in case the bandwidth (flits/cycle) is less than 1, the widthmay be kept the same or can be decreased, whereas in case the bandwidthis more than 1, the channel can be interpreted as being overloaded andthen width of the channel can be increased such that the bandwidth isreduced to 1 or less than 1.

According to one embodiment, buffer size of a buffer associated with theinput virtual channel can be adjusted based on the performance objectiveand the throughput of at least one of the input virtual channel andoutput virtual channel. According to another embodiment, buffer size ofa buffer also be associated with the output virtual channel can beadjusted based on the performance objective and the throughput of the atleast one of the output virtual channel and input virtual channel.

In an exemplary embodiment, extra bandwidth provisioning can also beincorporated so as to account for randomness of the traffic and in orderto support burstiness in the behavior of the traffic such that theefficiency of NoC is not compromised. In an instance, while sizing thewidth of the channel, burstiness behavior and/or randomness of thetraffic can be accounted by extra bandwidth provisioning. For instance,extra bandwidth provisioning of x % can be done such that the overloadload can be 1.0-x %.

FIGS. 4A and 4B illustrate an example NoC component 404 having multipleinput and output ports connecting the NoC component 404 with other NoCcomponents using virtual channels, which may cause loss of efficiencydue to NoC component (router) arbitration. As shown in the exampleillustration of FIG. 4A, NoC element 404 such as a router 404 can beoperatively coupled with two input channels 402-1 and 402-2,collectively and interchangeably referred hereinafter as input channels402, and two output channels 406-1 and 406-2, collectively andinterchangeably referred hereinafter as output channels 406. The NoCcomponent 404 can, for instance, be an on-chip router having two inputports at 402 and two output ports at 406. In an implementation, load onthe output channel may be acceptable and optimal when, say the inputchannel 402-1 sends traffic to output channel 406-1, and the inputchannel 402-2 sends traffic to the output channel 406-2. However, whenthe channel 402-1 also starts sending traffic to output channel 406-2,and/or the channel 402-2 starts sending traffic to output channel 406-1then due to conflicts during router arbitration, congestion can takeplace at the router channels. Based on traffic pattern, such conflictsduring router arbitration can cause loss of efficiency, wherein, forinstance, output channel 406-1 can process traffic from input channel402-1 with full efficiency (100%) and process traffic from input channel402-2 with half efficiency (50%), making the overall/net efficiency ofthe output channel to be 75%. This problem is even further aggravated incase of more number of input and output ports, wherein, as shown in FIG.4B, NoC component 454 has five input ports 452 and five output ports456, in which case, the efficiency loss on ports other than the one portthat is intended to directly process traffic from a given input port isreduced by a factor of 1-1/e, wherein e is the efficiency. The value ofefficient e may depend upon the traffic pattern and number of virtualchannels, and message sizes. In order to handle load and bandwidthrequirements in such a situation, efficiency of router and/or each ofits port can be computed, based on this input/output channels can beoversized automatically to compensate for the efficiency loss.Furthermore, in other words, load efficiency at each channel can becomputed and sizing can then be performed to compensate for the loss,wherein, in addition, if desired, extra bandwidth can also beprovisioned for during oversizing to meet additional unknown loss inefficiency for pathological traffic patterns and burstiness. Accordingto one embodiment, instead of sizing one or more given input/outputchannels, additional virtual channels can also be incorporated in orderto improve efficiency of the NoC architecture.

FIGS. 5A and 5B illustrate example NoC components that can use automaticsizing of channels and/or buffers in accordance with an embodiment ofthe present disclosure. FIG. 5A illustrates an example NoC component502-1 that may have two input virtual channels VC 504-1 and VC 504-2,each of 64 bits width, collectively and interchangeably referred asinput VCs 504, and an output virtual channel VC 506 of 128 bits width,that is wider than the two input VCs 504. An embodiment of the presentdisclosure is targeted for NoC components that may not multiplex packetsreceived at different input VCs 504 to the output VCs 506 due to variousreasons. When a NoC component 502-1 receives packets at two inputchannels VC 504-1 and VC 504-2, it can use routing arbitration method toschedule packets to be forwarded to the output VC 506 and uses a lockingmechanism that forwards packets/FLITs received from one input channelsay VC 504-1, and blocks packets/FLITs received from second inputchannel say VC 504-2. In such scenarios, NoC component 502-1 can lockthe output VC 506 for a limited time, for example, for one to two cyclesor for a time period that ensures that all the FLITs of scheduledpackets are forwarded. During the entire locking period, the period aninput VC has locked the output VC for full transmission of all flits ofa packet, the throughput at the 128-bit wide output VC will only be 50%,or it will observe a flit every other clock cycle, because input VCwidth is 64-bit and it can only supply packet at 64-bits/cycle. Due toimplementation of such locking mechanism, it can be observed that eventhough the size of the output VC 506 (128 bits) is equal to that of thecombination of the size of input VC 504-1 and of input VC 504-2, it maynot provide optimal efficiency, and bandwidth available at output VC 506may not be fully utilized, thereby reducing the overall throughput ofthe NoC component. In an example implementation, in order to improve thethroughput of the NoC component 502-1, input VCs 504-1 and/or VC 504-2can be upsized from 64 bits to 128 bits to enable reading/sending ofpackets at 128 bits/cycle. However, in spite of this, the output VC 506may not be fully utilized as the input channels may not receive morethan 64 bits per cycle from the previous NoC component 502-2, which hasnarrower VC widths of 64 bits.

In an example implementation, input VCs 504 can have associated bufferssuch as buffer 508-1 that is associated with input channel 504-1, andbuffer 508-2 that is associated with channel 504-2, both of which areconfigured to receive/store/forward data from respective input channelsto output channel 506. In an example implementation of the presentdisclosure, in order to optimize the sizing, when a packet is receivedat input channel say VC 504-1, the NoC component 502-1 can schedule theinput VC 504 to buffer the entire packet (may consist of several flits)from start of packet (SOP) to end of packet (EOP) without multiplexingit with packets of other input VC say VC 504-2, and then send the packetfrom the buffer 508 to the output VC 506 when the complete packet isbuffered or when the buffer is full. A channel having such aconfiguration can be referred to as store and forward channel, whereinthe complete packet is stored/buffered before being forwarded to theoutput channel. In case however, if the buffer is full, the alreadybuffered part of the packet can be sent, during which time, theremaining part of the packet can be buffered for subsequent issuance.According to one embodiment, such buffers 508 can be dynamically sizedbuffers.

According to one embodiment, in order to better utilize the widebandwidth output VC 506, data from input VC, example input VC 504-2, canbe stored in dynamic sized buffer for two cycles, and then forwardedtogether in the next cycle. However in such an implementation, theoutput VC channel 506 remains utilized half of the time. At one cycle,the output VC 506 may forward 128 bits, however in the second cycle, theoutput VC 506 remains idle. Similarly, in the third cycle, the output VC506 may forward 128 bits and remain idle in the fourth cycle. Therefore,the net bandwidth utilization of output VC 506 by NoC component 502-1 isonly 50% as the output VC 506 remains idle half the time, wherein inorder to further improve utilization of the wide output VC 506 and toget maximum throughput from the NoC component 502-1, NoC channelarbitration algorithm can be designed in such a way that when NoCcomponent 502-1 has multiple narrow channels and one wide channel, in anexample implementation, such traffic behavior (multiple narrow input VCand single narrow output VC) can be automatically detected and size ofthe input channels VC 504-1, VC 504-2 and/or size of the input buffers508-1, 508-2 can be upsized, say from 64 to 128 bits/cycle.

FIG. 5B illustrates another example NoC component 552 that has a wideinput channel, and two narrow output channels that can use automaticsizing of channels and/or buffers thereof in accordance with anembodiment of the present disclosure. As illustrated, NoC component 552can have one wide input channel 554 of 128 bits/cycle, and two outputchannels VC 556-1 and VC 556-2, collectively referred to as outputchannel(s) 556 hereinafter, of 64 bits each. In an exampleimplementation, where multiplexing/de-multiplexing of packets of twoinput/output VCs are not allowed, throughput of the NoC component 552-1may not be optimal. For instance, NoC component 552-1 may receiveflits/cycle at 128 bit per cycle but will only be able to forwardflits/cycle at 64 bit per cycle through its output VC 556-1 and/oroutput VC 556-2, thereby enabling drop in the throughput.

In an example implementation, throughout of the NoC component 502-1 canbe improved by automatically upsizing the width of the respective outputchannels 556 from 64 bits to 128 bits/cycle. In an exampleimplementation, such traffic behavior (single wide input VC and multiplenarrow output VCs) can be automatically detected, and size of the outputchannels and/or its output buffers 558-1 and 558-2 can be upsized tomeet the efficiency requirements. In an embodiment, other NoC componentssuch as NoC component 552-2 and NoC component 552-3 can be similarlyoptimized.

In an example embodiment, size of input/output buffer and/orinput/output VCs can be automatically upsized or downsized based on oneor more performance objectives, throughputs of input virtual channels,and throughout of output virtual channels. In an embodiment, throughputof the input virtual channels and of the output virtual channels can bebased on and/or can be derived from one or more of clock frequencies ofchannels, channel width, rate of traffic, and given trafficspecification of the NoC and SoC. According to an embodiment, theperformance objective can include one or a combination of rate oftraffic, message size, distribution of message size or channel width,channel clock frequency, arbitration efficiency of the NoC components,traffic burstiness, user-specified over provisioning, among other likeparameters/attributes. In another embodiment, the buffer size can beadjusted based on flow control turnaround time between a transmittinghardware element and a receiving hardware element.

FIG. 5C illustrates example NoC components 572 and 574, wherein size ofbuffer and data forwarding can be based on flow control in accordancewith an embodiment of the present disclosure. As illustrated, two NoCcomponents such as router 572 and 574 of a NoC interconnect can resizebuffers of their VCs based on block control. In example implementation,all ports and respective VCs of the NoC components maintain a creditupdate and forward the data based on available credit. In an exampleimplementation, when a router 572 sends data to router 574 over its VC576, router 574 can send back a credit through its VC 576 to the router572 after forwarding the packets through the output VC of the router574. When the router 572 sends data, it may decrement its credit andwhen it receives credit from router 574, it may increment its creditvalue. Such implementation can add latency to the system architecture asthe next set of flits may have to wait till credit is received back fromthe router 574. In such an implementation, buffer size can be increasedor decreased to match the turnaround time from data transmission tocredit return, to maintain full throughput. For instance, if theturnaround time is X cycle, output buffer 576 can be resized at X flitssuch that the output VC 576 of the router 572 has enough time to receivethe credit and to store flits received during that time period. In anexample, size of buffer can be proportional to the flow controlturnaround time and required throughput at the VC.

In an embodiment, buffer size can be adjusted based on clock frequenciesof the NoC components involved in the transaction. Aspects of thepresent system further include means for sizing a channel based on flowcontrol, wherein, for instance, in case it is determined by the proposedsystem that the router sending a request works at a different clockfrequency (C1) when compared with the clock frequency (C2) of thereceiving router, as the router times are different, buffer size of thereceiving buffers can be controlled/managed to enable efficientthroughput. In another example aspect, in case the proposed systemdetermines that the read frequency is less than write frequency, thereexists no need to maintain full throughput by means of additional buffersize as the read throughput is more than the write throughput and thedrain rate at the VC buffer would be lower. On the other hand, in casethe read frequency is more than or equal to the write frequency, the VCbuffer size can be deepened.

In an embodiment on the above-mentioned lines therefore, size of channelbuffer can also be dependent on whether the transmitting hardwareelement(s) and the receiving hardware element(s) are operating atsynchronous clock cycle. For such scenario, buffer can also be sized tostore the data received during to time period required to shift from oneclock domain to another clock domain as the NoC component may incur somelatency in time taken to change from one clock domain to another. Whentwo hardware elements engaged in communication are of different clockdomains, buffer sizes can be increased to accommodate such latency.

In an example implementation, size of the buffer can be calculated basedon one or a combination of bandwidth requirement, required performanceobjectives, frequency of transmitting hardware elements and receivinghardware elements, turnaround time in case of credit based packetforwarding. Calculation of buffer size can also include parameters,including but not limited to, possibility of randomness/burstiness. Inyet another example implementation, buffer can be sized to store X backto back flits in case on bursty traffic behavior, wherein X is thenumber derived from estimation of past bursty behavior.

In an example implementation, for a very large packet, the input buffercan be resized to store enough part of the packet and then startforwarding the data from buffer such that by the time first set of datais transmitted from the buffer to the output VC, remaining portion ofthe data of the packet arrives at the buffer. In an instance of a NoCcomponent having a narrow input channel of 64 bits/cycle, wide outputchannel of 128 bits/cycle, and each packet having a size of 16*64 bits(i.e. 16 flits), the buffer can be sized to store 11*64 bits at a giventime such that by the time by the 10th FLIT is transmitted from thebuffer to the output channel, remaining part of the packet arrives atthe buffer or is already buffered. One should appreciate that eventhrough the buffer may be small sized when compared with the full lengthof packet to be transmitted, it may have the same throughout as it canbe sized to store enough parts of packet so that the performance is nothampered. In an example implementation, size of buffer can be a functionof the input data rate, output data rate, and one or more definedperformance objectives, i.e., buffer size=F(input data rate, output datarate, performance objectives/parameters).

FIG. 6 illustrates a shared buffer architecture for input channel of NoCcomponent in accordance with an embodiment of the present disclosure. Asillustrated in FIG. 6, NoC component 602 can have 4 input channels suchas 604-1, 604-2, 604-3, and 604-4, collectively and interchangeablyreferred as input VCs 604 hereinafter, and 2 output channels such as606-1 and 606-2, collectively and interchangeably referred as output VC606 hereinafter. NoC component 602 can further include dedicated inputbuffers such as 608-1, 608-2, 608-3, and 608-4 respectively for eachinput VC 604, output buffers such as 612-1 and 612-2 for respectiveoutput VCs 606, and a shared buffer 610. In an example implementation ofthe present disclosure, instead of assigning dedicated buffers 608 oflarge sizes for each input VC 404, system of the present disclosure canconfigure a shared buffer 610 that can be accessed by any input VC 604in order to buffer its flits that are to be read out from the output VCs606. In an example implementation, shared buffer 610 can be dynamicallyand/or automatically be shared and partitioned between input VCs 604. Inanother embodiment, a selective set of input VC's can also be configuredto use the shared buffer 610 instead of allowing all the input VCs touse the buffer 610. In yet another embodiment, instead of or apart fromthe input VCs, output VC's can also be configured to use one or moreshared buffer configurations.

In another example embodiment, if it is determined that an input bufferdoes not have the capability to store the entire packet, clock frequencyof the corresponding input channel can be lowered to enable slowtransmission of data, in which case the same configuration can beapplied, wherein the input VC can lock with an output VC and keepsending the complete packet in a single go itself.

In another embodiment, channel/buffer optimizations can also cater forbursty traffic behavior, which may typically be slow but sometimes mayencounter back-to-back traffic on a given VC channel, in which case, thechannel may not have the capability to handle the burstiness. Therefore,aspects of the present disclosure can include a metric that defines howmuch burstiness can be handled by a channel or by multiple channels, andhow many back to back packets of the same flow may need to be handled.For instance, if 3 back-to-back packets need to be handled, the same canbe recorded as a constraint, and the FIFO buffers can be resizedaccordingly. Therefore, in total, instead of 1, a total of 4 packets(including 3 back-to-back packets) may need to be handled and thereforethe buffers can be resized accordingly by creating additional bufferspace.

FIG. 7 illustrates an example flow diagram 700 for automatically sizingof buffers of input/output channel(s) in accordance with an embodimentof the present disclosure. At step 702, load/bandwidth and performanceobjectives expected to be handled by a channel can be computed based onone or a combination traffic flows on the channel, rate of each flow,size of each message in each flow, distribution pattern of each message,current width of the channel, clock frequency of the channel, amongother like parameters. At step 704, based on the computed load/bandwidthand performance objectives of this channel and of the upstream channelsto which this channel sends data, and of the downstream channels fromwhich this channel receives data, the channel and/or buffers thereof canbe sized in terms of their width and depth so as to meet theload/bandwidth and performance objectives.

FIG. 8 illustrates an example computer system 800 on which exampleimplementations may be implemented. The computer system 800 includes aserver 805 which may involve an I/O unit 835, storage 860, and aprocessor 810 operable to execute one or more units as known to one ofskill in the art. The term “computer-readable medium” as used hereinrefers to any medium that participates in providing instructions toprocessor 810 for execution, which may come in the form of computerreadable storage mediums, such as, but not limited to optical disks,magnetic disks, read-only memories, random access memories, solid statedevices and drives, or any other types of tangible media suitable forstoring electronic information, or computer readable signal mediums,which can include media such as carrier waves. The I/O unit processesinput from user interfaces 840 and operator interfaces 845 which mayutilize input devices such as a keyboard, mouse, touch device, or verbalcommand.

The server 805 may also be connected to an external storage 850, whichcan contain removable storage such as a portable hard drive, opticalmedia (CD or DVD), disk media or any other medium from which a computercan read executable code. The server may also be connected an outputdevice 855, such as a display to output data and other information to auser, as well as request additional information from a user. Theconnections from the server 805 to the user interface 840, the operatorinterface 845, the external storage 850, and the output device 855 mayvia wireless protocols, such as the 802.11 standards, Bluetooth® orcellular protocols, or via physical transmission media, such as cablesor fiber optics. The output device 855 may therefore further act as aninput device for interacting with a user.

The processor 810 may execute one or more modules. System 800 caninclude a processor operatively coupled with a memory and with ahardware element having an input port associated with an input virtualchannel and an associated output port associated with an output virtualchannel, wherein the system can include an input virtual channel widthsizing module 812 configured to size a width of the input virtualchannel based on a performance objective and a throughput of at leastone of the input virtual channel and output virtual channel. System 800can further include an output virtual channel width sizing module 814configured to size a width of the output virtual channel based on theperformance objective and a throughput at least one of the outputvirtual channel and input virtual channel. System 800 can furtherinclude a input virtual channel buffer size adjustment module 816configured to adjust a buffer size of a buffer associated with the inputvirtual channel based on the performance objective and the throughput ofat least one of the input virtual channel and output virtual channel.System 800 can further include an output virtual channel buffer sizeadjustment module 818 configured to adjust a buffer size of a bufferassociated with the output virtual channel based on the performanceobjective and the throughput of the at least one of the output virtualchannel and input virtual channel. In an aspect of the proposed system800, throughput of the input virtual channel and the output virtualchannel can be derived from one or more of clock frequency, channelwidth and traffic specification. In another aspect, performanceobjective can be based on at least one of rate of traffic, message sizedistribution of the traffic, channel width, channel clock frequency,arbitration efficiency of the router, traffic burstiness, and specifiedoverprovisioning. In yet another aspect of the proposed system 800,adjustment of the buffer size can include adjustment of the buffer sizebased on the performance objective, and input/output message sizes andinput/output message rate. In yet another aspect of the proposed system800, adjustment of the buffer size can be based on a flow controlturnaround time between a transmitting hardware element and a receivinghardware element. In yet another aspect, adjustment of the buffer sizecan be based on a clock frequency of a transmitting hardware element anda receiving hardware element. As also mentioned above, hardware elementcan be any or a combination of a router and a bridge or any other NoCelement.

In some example implementations, the computer system 800 can beimplemented in a computing environment such as a cloud. Such a computingenvironment can include the computer system 800 being implemented as orcommunicatively connected to one or more other devices by a network andalso connected to one or more storage devices. Such devices can includemovable user equipment (UE) (e.g., smartphones, devices in vehicles andother machines, devices carried by humans and animals, and the like),mobile devices (e.g., tablets, notebooks, laptops, personal computers,portable televisions, radios, and the like), and devices designed forstationary use (e.g., desktop computers, other computers, informationkiosks, televisions with one or more processors embedded therein and/orcoupled thereto, radios, and the like).

Unless specifically stated otherwise, as apparent from the discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing,” “computing,” “calculating,” “determining,”“displaying,” or the like, can include the actions and processes of acomputer system or other information processing device that manipulatesand transforms data represented as physical (electronic) quantitieswithin the computer system's registers and memories into other datasimilarly represented as physical quantities within the computersystem's memories or registers or other information storage,transmission or display devices.

Example implementations may also relate to an apparatus for performingthe operations herein. This apparatus may be specially constructed forthe required purposes, or it may include one or more general-purposecomputers selectively activated or reconfigured by one or more computerprograms. Such computer programs may be stored in a computer readablemedium, such as a computer-readable storage medium or acomputer-readable signal medium. A computer-readable storage medium mayinvolve tangible mediums such as, but not limited to optical disks,magnetic disks, read-only memories, random access memories, solid statedevices and drives, or any other types of tangible or non-transitorymedia suitable for storing electronic information. A computer readablesignal medium may include mediums such as carrier waves. The algorithmsand displays presented herein are not inherently related to anyparticular computer or other apparatus. Computer programs can involvepure software implementations that involve instructions that perform theoperations of the desired implementation.

Various general-purpose systems may be used with programs and modules inaccordance with the examples herein, or it may prove convenient toconstruct a more specialized apparatus to perform desired method steps.In addition, the example implementations are not described withreference to any particular programming language. It will be appreciatedthat a variety of programming languages may be used to implement theteachings of the example implementations as described herein. Theinstructions of the programming language(s) may be executed by one ormore processing devices, e.g., central processing units (CPUs),processors, or controllers.

As is known in the art, the operations described above can be performedby hardware, software, or some combination of software and hardware.Various aspects of the example implementations may be implemented usingcircuits and logic devices (hardware), while other aspects may beimplemented using instructions stored on a machine-readable medium(software), which if executed by a processor, would cause the processorto perform a method to carry out implementations of the presentdisclosure. Further, some example implementations of the presentdisclosure may be performed solely in hardware, whereas other exampleimplementations may be performed solely in software. Moreover, thevarious functions described can be performed in a single unit, or can bespread across a number of components in any number of ways. Whenperformed by software, the methods may be executed by a processor, suchas a general purpose computer, based on instructions stored on acomputer-readable medium. If desired, the instructions can be stored onthe medium in a compressed and/or encrypted format.

Moreover, other implementations of the present disclosure will beapparent to those skilled in the art from consideration of thespecification and practice of the teachings of the present disclosure.Various aspects and/or components of the described exampleimplementations may be used singly or in any combination. It is intendedthat the specification and example implementations be considered asexamples only, with the true scope and spirit of the present disclosurebeing indicated by the following claims.

What is claimed is:
 1. A method for generating a Network on Chip (NoC),comprising: generating the NoC comprising a hardware element having aninput port associated with an input virtual channel and an associatedoutput port associated with an output virtual channel, the generatingthe NoC comprising: sizing a width of the input virtual channel based ona performance objective and a throughput of at least one of the inputvirtual channel and output virtual channel; sizing a width of the outputvirtual channel based on the performance objective and a throughput atleast one of the output virtual channel and input virtual channel; andadjusting a buffer size of a buffer associated with the input virtualchannel based on the performance objective and the throughput of atleast one of the input virtual channel and output virtual channel;adjusting a buffer size of a buffer associated with the output virtualchannel based on the performance objective and the throughput of the atleast one of the output virtual channel and input virtual channel;wherein the hardware element is one of a router and a bridge.
 2. Themethod of claim 1, wherein the throughput of the input virtual channeland the output virtual channel is derived from one or more of: clockfrequency, channel width and traffic specification.
 3. The method ofclaim 1, wherein the performance objective is based on at least one of:rate of traffic, message size distribution of the traffic, channelwidth, channel clock frequency, arbitration efficiency of the router,traffic burstiness, and specified overprovisioning.
 4. The method ofclaim 1, wherein the adjusting the buffer size comprises adjusting thebuffer size based on the performance objective, and input/output messagesizes and input/output message rate.
 5. The method of claim 1, whereinthe adjusting the buffer size is based on a flow control turnaround timebetween a transmitting hardware element and a receiving hardwareelement.
 6. The method of claim 1, wherein the adjusting the buffer sizeis based on a clock frequency of a transmitting hardware element and areceiving hardware element.
 7. A non-transitory computer readable mediumstoring instructions for executing a process for generating a Network onChip (NoC), the instructions comprising: generating the NoC comprising ahardware element having an input port associated with an input virtualchannel and an associated output port associated with an output virtualchannel, the generating the NoC comprising: sizing a width of the inputvirtual channel based on a performance objective and a throughput of atleast one of the input virtual channel and output virtual channel;sizing a width of the output virtual channel based on the performanceobjective and a throughput at least one of the output virtual channeland input virtual channel; and adjusting a buffer size of a bufferassociated with the input virtual channel based on the performanceobjective and the throughput of at least one of the input virtualchannel and output virtual channel; adjusting a buffer size of a bufferassociated with the output virtual channel based on the performanceobjective and the throughput of the at least one of the output virtualchannel and input virtual channel; wherein the hardware element is oneof a router and a bridge.
 8. The non-transitory computer readable mediumof claim 7, wherein the throughput of the input virtual channel and theoutput virtual channel is derived from one or more of: clock frequency,channel width and traffic specification.
 9. The non-transitory computerreadable medium of claim 7, wherein the performance objective is basedon at least one of: rate of traffic, message size distribution of thetraffic, channel width, channel clock frequency, arbitration efficiencyof the router, traffic burstiness, and specified overprovisioning. 10.The non-transitory computer readable medium of claim 7, wherein theadjusting the buffer size comprises adjusting the buffer size based onthe performance objective, and input/output message sizes andinput/output message rate.
 11. The non-transitory computer readablemedium of claim 7, wherein the adjusting the buffer size is based on aflow control turnaround time between a transmitting hardware element anda receiving hardware element.
 12. The non-transitory computer readablemedium of claim 7, wherein the adjusting the buffer size is based on aclock frequency of a transmitting hardware element and a receivinghardware element.
 13. A system configured to generate a Network on Chip(NoC), comprising: a processor operatively coupled with a memory andconfigured to generate a NoC comprising a hardware element having aninput port associated with an input virtual channel and an associatedoutput port associated with an output virtual channel and to executeeach module in the memory, said memory comprising: an input virtualchannel width sizing module configured to size a width of the inputvirtual channel based on a performance objective and a throughput of atleast one of the input virtual channel and output virtual channel; anoutput virtual channel width sizing module configured to size a width ofthe output virtual channel based on the performance objective and athroughput at least one of the output virtual channel and input virtualchannel; input virtual channel buffer size adjustment module configuredto adjust a buffer size of a buffer associated with the input virtualchannel based on the performance objective and the throughput of atleast one of the input virtual channel and output virtual channel; andan output virtual channel buffer size adjustment module configured toadjust a buffer size of a buffer associated with the output virtualchannel based on the performance objective and the throughput of the atleast one of the output virtual channel and input virtual channel;wherein the hardware element is one of a router and a bridge.
 14. Thesystem of claim 13, wherein the throughput of the input virtual channeland the output virtual channel is derived from one or more of: clockfrequency, channel width and traffic specification.
 15. The system ofclaim 13, wherein the performance objective is based on at least one of:rate of traffic, message size distribution of the traffic, channelwidth, channel clock frequency, arbitration efficiency of the router,traffic burstiness, and specified overprovisioning.
 16. The system ofclaim 13, wherein adjustment of the buffer size comprises adjustment ofthe buffer size based on the performance objective, and input/outputmessage sizes and input/output message rate.
 17. The system of claim 13,wherein adjustment of the buffer size is based on a flow controlturnaround time between a transmitting hardware element and a receivinghardware element.
 18. The system of claim 13, wherein adjustment of thebuffer size is based on a clock frequency of a transmitting hardwareelement and a receiving hardware element.